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ABSTRACT 

This  paper  proposes  building  knowledge- based  s>-steujs 
using  a  programnaing  system  based  on  a  very- high- level 
language.  It  gives  an  overview  of  such  a  programming 
system,  BC,  and  shows  how  BC  can  be  used  to  implement 
knowledge  representation  features,  providing  as  examples, 
automatic  maintenance  of  inverse  links  and  property  in¬ 
heritance.  The  specification  language  of  BC  can  be  ex¬ 
tended  to  include  a  knowledge  representation  language 
by  describing  its  knowledge  representation  features.  This 
permits  a  knowledge-based  program  and  it"  knowledge 
base  to  be  written  in  the  same  very-high-level  language 
which  allows  the  knowledge  to  Lr  were  eflficiently  incor¬ 
porated  into  the  program  as  well  as  making  the  system  as 
a  whole  easier  to  understand  aitd  extend. 


§1  Introduction 

A  knowledge-based  system  typically  consists  of  a  pro¬ 
gram  and  a  knowledge  base  that  the  program  uses.  The 
knowledge  base  is  expressed  in  a  special  knowledge  repre¬ 
sentation  language  that  is  essentially  a  very-high-level  lan¬ 
guage  that  the  program  interprets.  This  paper  describes 
a  very- high- level  language  programming  system,  BC,  and 
shows  how  BC  can  be  used  to  define  knowledge  repre¬ 
sentation  languages  so  that  they  can  be  efficiently  com¬ 
piled.  Furthermore,  the  knowledge-based  program  itself 
can  be  specified  in  BC  using  the  same  techniques  with 
the  same  advantages  of  ease  of  comprehension  and  main¬ 
tainability  that  are  associated  with  the  knowledge  base. 
This  allows  the  knowledge  base  to  be  viewed  as  part  of 
the  specification  of  the  program,  which  is  the  key  to  its 
efficient  incorporation  into  the  program.  In  this  way  BC 
may  be  viewed  as  a  knowledge  compiler,  pre- processing 
knowledge  so  that  it  is  used  efficiently  in  the  knowlcdge- 
based  system. 


This  research  is  supported  in  part  by  the  Defense  Advanced  Re¬ 
search  Projecu  Agency  Contract  N00014-81-C-0582,  monitored  by 
the  Office  of  Naval  Research.  The  views  and  conclusions  contained 
in  this  paper  are  those  of  the  author  and  should  not  be  interpreted 
as  representing  the  official  policies,  either  expressed  or  impUed  of 
KESTREL,  DARPA,  ONR  or  the  US  Covernment. 


BC  allows  programs  to  be  factored  into  a  descrip¬ 
tion  of  the  problem  to  be  solved  and  a  description  of 
the  implementation  of  the  solution.  The  implementation 
description  can  include  schemes  for  representing  entities 
of  the  problem  description  or  solving  particular  types  of 
sub-problem.  BC  can  be  used  to  define  implementation 
schemes  for  knowledge  representation  features  such  as 
property  inheritance,  inverse  link  maintenance,  and  proce¬ 
dural  attachment.  The  definitions  of  the  first  two  of  these 
features  are  given  later  in  this  paper.  BC  is  described 
fully  in  [Westfold,  1984). 

The  specification  language  for  BC  is  basically  a  mathe¬ 
matical  language  including  logic,  sets,  relations,  and  func¬ 
tions.  This  very-high-level  language  is  convenient  for 
defining  new  language  constructs  in  terms  of  existing  con¬ 
structs,  and  there  is  a  mechanism  for  defining  syntax  for 
the  new  constructs.  Thus  the  system  designer  can  define 
a  language  that  is  convenient  for  system  users;  the  parser 
converts  this  language  into  relations  that  are  defined  in 
terms  of  mathematical  objects  that  have  properties  that 
facilitate  their  manipulation  (compilation)  by  BC.  By  use 
of  manipulation  such  as  equivalence  transformation  BC 
can  produce  an  implemented  program  whose  structure  is 
quite  different  from  that  of  the  problem  specification.  In 
other  words,  convenient,  uniform  interfaces  can  be  defined 
for  the  user  and  to  facilitate  the  description  of  the  different 
components  of  the  system,  but  the  implementation  can  be 
non-uniform,  crossing  interfaces  and  taking  advantage  of 
different  views  of  the  problem  domain  in  order  to  produce 
an  efficient  program. 

The  ideas  ih  this  paper  are  being  tested  by  using  BC 
in  building  the  CHI  knowledge-based  programming  sys¬ 
tem  [Green  et  al.,  1981).  CHI  includes  the  following  com¬ 
ponents,  all  of  which  make  use  of  BC  in  their  specification 
and  implementation:  data  structure  selection,  algorithm 
design,  parallel  algorithm  derivation,  and  project  manage¬ 
ment,  the  database  manager,  program  analysis,  finite 
differencing,  and  BC  itself.  Many  of  these  components  are 
useful  in  building  knowledge- baised  systems,  so  CHI  as  a 
whole  is  better  than  just  BC  for  building  knowledge- based 
systems. 
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S2  Overview  of  BC 


BC  is  essentially  a  compiler  that  produces  Lisp  code 
from  a  specification  in  the  form  of  logic  assertions.  The 
specification  consists  of  three  parts:  the  basic  definition 
of  the  problem  domain;  the  definition  of  auxiliary  ob¬ 
jects  that  are  needed  in  an  efficient  implementation  of  the 
problem  domain;  and  information  about  how  the  defining 
assertions  are  to  be  used  procedurally.  It  is  convenient  to 
identify  and  use  an  intermediate  rule  language  in  going 
from  the  logic  assertion  language  to  procedural  Lisp.  A 
rule  specifies  an  action  (procedure)  in  terms  of  its  precon¬ 
dition  (applicability  condition]  and  postcondition  (what  is 
true  after  its  application).  A  rule  consists  of  two  logical 
formulas,  written  as 

P  Q 

where  P  is  the  precondition  and  Q  is  the  postcondition. 
(Note  that  ‘  ’  is  a  procedural  construct  and  ‘=»’  is  the 

symbol  for  implication.) 

The  part  of  BC  that  compiles  the  logic  assertion 
specification  into  rules  U  ca'lcd  the  Logic  Assertion 
Compiler  (LAC).  From  an  assertion,  which  could  be  used 
to  make  many  different  inferences,  and  instructions  stat¬ 
ing  which  particular  inference  and  in  what  context,  LAC 
produces  a  rule  that  is  a  specification  of  that  particular 
inference.  The  part  of  BC  that  compiles  rules  into  Lisp 
is  the  Rule  Compiler  (RC).  It  works  by  a  process  of  step¬ 
wise  refinement  similar  to  other  transformational  systems 
such  as  PECOS  (Barstow,  1979j,  TI  (Balter,  I9SIj,  and 
[Burstall  and  Darlington,  1977).  At  intermediate  stages  of 
refinement  the  program  contains  a  mixture  of  constructs 
from  very-high-level  to  low-level,  so  a  wide-spectrura  lan¬ 
guage  must  be  used  that  includes  all  these  constructs  in  a 
unified  framework. 


LAC  Logic  Assertion  Compiler 


RC  Rule  Compiler 


Figure  1.  Structure  of  BC 


The  language  used  by  BC  is  called  V  and  it  is  the 
language  used  throughout  CHI.  V  was  mitially  defined 
by  Phillips  {Phillips,  1982)  and  has  since  been  refined 
and  extended  by  the  CHI  group  It  contains  a  number 
of  integrated  sub- languages:  a  first-order  predicate  logic 
language,  VLogic,  which  is  the  basic  specification  language 
used  by  BC;  a  rule  language,  VRL;  a  procedural  language, 
VP;  and  the  target  language  Lisp. 

2.1  Procedural  Use  of  Assertions 

LAC  compiles  a  specification  written  in  \'Logic  asser¬ 
tions  by  converting  each  assertion  into  an  inference  pro¬ 
cedure  specialized  to  that  assertion.  The  user  specifies 
which  particular  inference  procedure  should  be  used  BC 
provides  three  dimensions  of  choice  for  the  type  of  in¬ 
ference  procedure.  The  first  corresponds  to  the  general 
form  of  the  assertion  that  is  used,  either  an  implication 

P  =»  9 

or  an  equality  (with  equivalence  considered  a  special  case 
of  equality) 

p=q. 

Each  of  the  general  forms  may  have  a  precondition  which 
is  written  as  the  antecedent  of  an  implication  with  the 
form  as  the  consequent.  For  example:  r  =9  p  —  q  can  be 
considered  an  equality  with  precondition  r.  It  may  also 
be  treated  as  an  implication. 

The  second  dimension  corresponds  to  the  direction  of 
use  of  the  general  form:  from  left  to  right  or  right  to 
leK.  For  implication,  the  former  corresponds  to  forward 
or  data-driven  inference  and  the  latter  to  backward  or_ 
goal-directed  inference.  Considering  the  assertion  as  a 
constraint,  the  former  corresponds  to  enforcing  the  con¬ 
straint  and  the  latter  to  using  or  taking  advantage  of 
the  constraint.  An  equality  is  commutative,  but  typically 
there  is  a  directionality  associated  with  each  one.  For  ex¬ 
ample,  a  function  /  can  be  defined  using  an  equality  of 
the  form  /(r)=def. 

The  third  dimension  is  choice  of  compile-time  versus 
run-time  use  of  an  assertion.  Use  of  an  assertion  at  com¬ 
pile  time  provides  the  possibility  for  circumventing  the 
clean  specification-level  interfaces  and  producing  efficient, 
tangled  code.  The  result  of  compiling  an  assertion  for 
compile-time  use  is  a  procedure  that  affects  the  compila¬ 
tion  of  other  code. 

An  important  use  of  assertions  at  compile  time  is  to 
maintain  and  use  them  as  constraints.  Constraint  incor¬ 
poration  is  done  at  the  stage  of  compilation  where  a  proce¬ 
dure  is  expressed  as  a  rule.  Rule  compilation  involves  us¬ 
ing  the  rule  to  form  a  statement  in  logic  of  the  relationship 
between  the  computation  states  before  and  after  the  rule 
application,  and  then  producing  a  procedure  that,  given 
an  initial  state,  will  produce  a  new  state  that  satisfies 
the  relationshfp.  The  intermediate  statement  in  logic  is  a 
convenient  form  for  performing  inference  to  incorporate 
constraints  stated  in  logic  assertions. 


Use  of  an  assertion  at  run  time  requires  converting 
it  to  the  run-time  constructs  available  in  the  target  en¬ 
vironment.  Therefore  we  need  to  consider  two  models 
of  computation:  the  model  of  computation  as  inference 
at  the  specification  level  and  the  Lisp  model  which  is 
basically  a  recursive  function  model.  This  means  that 
any  run-time  inferences  have  to  be  put  into  a  functional 
form.  Goal-directed,  run-time  inference  can  be  imple¬ 
mented  efiBciently  using  Lisp  functions.  This  may  involve 
adding  an  extra  definition  so  that  the  goal  is  in  the  form 
of  a  function  call. 

In  order  to  implement  forward- inference  procedures  we 
need  some  extra  machinery  in  the  target  environment. 
The  procedures  need  to  be  attached  somewhere  so  that 
they  are  triggered  at  the  appropriate  time,  and  they  need 
to  be  able  to  store  the  value:  that  they  compute  sc  that 
the  values  aue  found  when  wanted.  This  can  be  done 
with  a  database  of  (function,  argument,  value]  triples 
that  are  indexed  by  the  function  and  argument.  BC 
uses  a  database  that  stores  objects  (the  things  that  may 
be  function  arguments)  as  mappings  from  functions  to 
values.  Functions  that  are  treated  in  this  way  are  called 
properties.  Storing  the  value  of  a  property  in  the  database 
may  trigger  attached  forward  inference  procedures  which 
may  store  values  for  other  properties.  When  the  value 
of  a  property  is  needed,  the  database  is  examined  to  see 
if  there  is  a  stored  value,  otherwise  a  Lisp  function  for 
computing  the  value  is  called,  if  there  is  one. 


2.2  Specifying  How  to  Use  an  Assertion 

The  ways  an  assertion  is  used  are  specified  by  attach¬ 
ing  simple  meta-assertions  to  the  assertion.  This  section 
describes  the  basic  options  provided  by  BC. 

Run-time  use  is  encapsulated  as  a  function.  For  for¬ 
ward  use  it  is  necessary  to  specify  the  triggering  form  that 
causes  the  function  to  be  called.  For  backward  use  it  is 
necessary  to  specify  the  name  of  the  function  whose  value 
is  to  be  computed; 

triggered- by  form),  form2,  ... 

(the  formi  are  the  triggering  forms) 

computes  fni,  fnj,  ...  (Closed  functions) 

(the  fn,'  are  the  functions  to  be  computed) 

Other  options  are; 

memo  (Save  computes  values  in  database) 

check  (Give  an  error  if  assertion  violated) 

For  compile-time  use  it  is  necessary  to  specify  whether 
the  assertion  is  to  be  used  as  a  constraint  for  optimisa¬ 
tion  or  as  a  constraint  to  be  maintained  (or  both),  or  for 
transforming  some  forms  into  equivalent  ones. 

compile-optimise  form  (Backward) 

(Use  the  assertion  to  remove  redundant  tests) 


eompile^in-line  form  (Forward) 

(Add  in-line  code  to  maintain  the  constraint) 
compile-transform  form 

(Transform  form  to  an  equivalent  form) 

For  convenience  the  forms  may  be  referred  to  by  their 
primary  funciion  if  this  is  an  unambiguous  referent. 

These  are  the  basic  meta-level  annotations.  Internally, 
they  are  simply  meta-level  properties  of  assertions-  New 
annotations  can  be  defined  in  terms  of  these  basic  ones 
using  logic  assertions  at  the  meta-level  from  «hich  BC  can 
produce  demons  that,  given  the  new  annotation,  generate 
the  equivalent  basic  annotations. 


2.3  The  Implementation  of  BC 

BC  is  written  primarily  in  its  own  languages — VLogic 
and  VRL.  A  basic  version  of  RC  was  written  in  Lisp  and 
then  the  VRL  specification  of  RC  was  compiled  and  this 
version  replaced  the  Lisp  version.  The  implementation 
of  LAC  is  at  the  stage  where  it  can  compile  assertions 
given  in  the  exact  form  needed  for  the  particular  use  of 
it.  The  part  of  LAC  that  preprocesses  assertions  to  get 
them  into  the  correct  form  has  been  designed  and  is  in  the 
process  of  being  implemented.  BC  has  been  developed  in 
Interiisp  (Teitelman  and  Masinter,  1981]  on  a  DEC  2060 
machine  and  then  in  Zelalisp  (Weinreb  and  Moon,  1981) 
using  the  Interlisp  Compatibility  Package  on  Symbolics 
3600  machines. 


§3  Example  Implementations  of  Knowledge 
Representation  Features 

The  examples  begin  with  a  simple  database  that  only 
provides  storage  and  retrieval  of  binary-relation  triples. 
This  is  used  as  the  basis  for  defining  knowledge  repre¬ 
sentation  features.  The  examples  presented  ate  fvi  mai.n- 
tenance  of  inverse  links  and  property  inheritance.  Other 
features  that  have  been  specified  are  specialized  treatment 
of  transitivity,  attached  procedures,  and  memoing  of  com¬ 
puted  properties. 

3.1  Maintaining  Inverse  Links 

The  first  example  is  the  task  of  maintaining  inverse 
links  in  a  database.  This  requires  that  whenever  /(z)=V 
is  stor>’d  in  the  database,  /~'(y)=z  is  also  stored.  The 
language  used  is  introduced  informally  as  necessary.  The 
basic  assertion  is: 

ini;efse(/)=: j  A  one-to-one {f)  =* 

/(t)=V  =  p(y)=i 

By  convention,  unbound  variables  are  universally 
quantified,  so/,  g,  z  and  y  are  universally  quantified  over 
this  assertion. 
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3.1.1  Maintaining  the  Constraint  with  a  Run-time 
Procedure 

One  way  of  maintaining  the  constraint  is  to  attach 
a  demon  function  that  is  executed  to  add  the  inverse 
whenever  a  property  is  stored.  This  can  be  specified  as 
follows; 

inverse(/^=9  A  one-to-one(/) 

/(i)=p  =  j(y)=* 

triggered-by  /(x)=v 

where  “triggered-by  p"  is  a  meta-level  annotation  that 
means  whenever  p  is  asserted  (stored)  the  assertion  should 
be  made  true. 

LAC  produces  the  following  demon  from  this 
specification: 

trigger  /(t)=y 

inverse (/)—  g  A  one-to-one (/)  A  -> DB(g(y)=x) 

-  DB{g{v)=t) 

This  uses  a  generalized  demon  construct  which  con¬ 
sists  of  a  triggering  event — in  this  case  the  assertion  that 
/{r)=y,  and  a  procedure  body — in  this  case  a  rule  whose 
applicability  condition  (leR-hand  side)  is  inveTBe{f]—g  A 
one-to-one(f)  A  ^  DB(g{y)=x)  and  whose  action  is  to 
make  its  right-hand  side  DB(g{y)—x)  true  in  the  new 
state.  DB(x)  is  true  if  and  only  if  x  is  stored  in  the 
database.  The  DB  predicate  is  used  to  distinguish  some¬ 
thing  that  is  true  because  it  is  explicitly  stored  in  the 
database  from  something  being  true  because  it  is  im¬ 
plied  by  the  database.  Thus  the  condition  -•  DB(g(y)=‘z) 
prevents  the  rule  from  applying  if  its  action  would  be 
redundant.  This  prevents  the  possibility  of  infinite  and 
ineETectual  forward  chaining. 

RC  compiles  the  rule  into  the  following  Clisp  code: 

(if  (db-get  f  'one-to-one) 

then  (let  ((g  (db-get  f  'inverse))) 

(if  (NEQ  (db-get  y  g)  x) 
then  (db-put  y  g  x)))) 

which  is  executed  whenever  a  property  is  stored  in  the 
database,  (db-get  x  y)  and  (db-put  x  y  z)  are  functions 
for  retrieving  from  and  storing  into  the  database,  respec¬ 
tively.  Basically  what  RC  does  in  this  simple  example 
is  decide  the  order  in  which  conjuncts  are  used  and  how 
each  conjunct  is  to  be  used — either  tested  or  used  to  bind 
a  variable. 


3.1.2  Maintaining  the  Constraint  with  In-line  Code 

An  alternative  way  to  maintain  the  constraint  is  to  add 
in-line  code,  specified  as  follows: 

inveTte(/)=g  A  on«-to-one(/)  =» 

/(z)—y  s  g{y)~x 
eomptle-in-line  /(x)=y 

where  "compile-in-line  p”  means  that  whenever  code 


that  makes  p  true  is  being  compiled,  add  extra  code  to 
make  the  assertion  true. 

The  compile- time  rule  procedure  for  adding  this  in-line 
code  is: 

a=*  Satisfy  {f(x)=yY 

A  inverse[f)~g  A  one-to-one{f) 

•—  n=‘5ofij/y(/(i)=y  A  p(y)=r)’ 

which,  for  example,  transforms  Satisfy{ths(m)=n) 
into  Satisfy  {lhs[m)—n  A  lhsof{n)=m)  where 
inverse (lhs)=lhs- of .  The  forms  in  single  bold  quotes  act 
as  patterns  that  on  the  leh-hand  side  match  expressions 
rnd  on  the  right-hand  side  cause  new  expressions  to  be 
constructed.  Satisfy{p)  means  change  the  state  to  make 
p  be  true.  It  is  used  as  an  intermediate  form  in  compil¬ 
ing  rules,  that  is  later  transformed  into  code  to  make  the 
desired  change  of  state. 

The  constraint  may  also  be  used  to  optimize  a  test  of 
/(^)=y  ^  just.  f{x)  —  y.  It  may 

also  be  used  to  replace  /(r)  =  y  by  /~'(y)  =  7,  which  is 
useful,  for  example,  when  another  rule  is  looking  for  r  as 
a  function  of  y. 


3.2  Property  Inheritance 

This  section  shows  how  an  implementation  scheme  can 
be  described  by  stating  a  single  invariant  and  the  ways 
that  it  is  to  be  maintained  and  used.  BC  derives  code  for 
each  of  the  procedures  that  maintain  or  use  the  invariant 
from  the  single  specification  of  the  invariant,  so  all  the 
procedures  are  consistent. 

The  type  of  property  inheritance  in  this  example  is  all 
members  of  a  set  having  the  same  value  for  a  property. 
For  example,  if  all  elephants  are  the  color  grey,  and  Clyde 
is  an  elephant,  then  we  can  deduce  that  Clyde  is  the  color 
grey.  Using  VLogic  these  statements  are: 

if  elephants  =»  color(i)=grey 

and  Clyde  €  elephants 

then  the  database  system  should  deduce  that 
color  (Clyde)=grey 
when  asked  for  color  (Clyde). 

A  scheme  for  doing  this  is  for  each  property  that  has 
this  inheritance  behavior  (e.g.  color),  to  introduce  a  cor¬ 
responding  property  that  applies  to  the  set  as  a  whole 
(e.g.  coioT-of-all)  and  connect  these  two  properties  by  the 
property  all-prop  (so  all-pTop{color)=color-of-all). 

This  scheme  can  be  described  by  the  invariant; 

{*  €  S  p[z]sxp.of-al!{S))  S  all-pTop[p)=p-of-all 

In  the  following,  1  refer  to  this  as  the  “scheme 
invariant.”  We  want  to  use  this  invariant  to 
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compute  p(x)  "when  applicable.  For  example,  the 
value  of  co/or(Clyde)  is  coior-o/-oi/(elephanta)  because 
ail-prop(color)=eoior-i>f  all .  To  maintain  the  invariant 
we  need  to  update  all-prop  and  the  instances  of  p-of-atl. 
For  example,  when  S  =*eotor(x)~eolor-of-aU{S)  is  as¬ 
serted,  we  need  to  make  all-pTop(eoloT)=color-o/-aU,  and 
later,  when  i  €  elephants  =»  color  (x)=grey  is  asserted,  we 
need  to  make  co/or-o/-o//{elephants)=gTey.  These  uses 
of  the  assertion  are  expressed  by  saying  that  it  is  used 
to  compute  p  and  used  to  maintain  all-prop  and  p-of-all. 
The  complete  specification  of  this  in  BC  is; 

(x£S  =>  piz)—p-of-all{S))  s  all-pTop[p)=p-of-all 
computes  p 

triggered-by  x£S  ^  p(j)=t/, 

*  €  5  =♦  p(x}=p-o/-all(S) 

Before  looking  at  how  each  of  the  three  procedures 
is  derived  from  this  specification,  we  mention  an  alter¬ 
native,  similar  scheme  to  emphasiie  that  this  constraint 
could  be  used  in  different  ways:  instead  of  computing  p 
when  needed  it  could  be  maintained.  In  this  case,  when 
Clyde  €  elephants  is  stored  then  co/or  (Clyde)=gTey  is  also 
stored. 

3.2.1  Computing  an  Inherited  Property 

The  first  case  is  deriving  a  partial  procedure  for  com¬ 
puting  p(z)  from  the  scheme  invariant,  for  example  com¬ 
puting  eo/of  (Clyde]  as  color-o/-al/(elephants).  First  LAC 
converts  the  scheme  invariant  to  the  form  r=»p(r)=d  by 
treating  the  equivalence  as  a  right- to-left  implication  and 
merging  the  nested  implications  into  a  single  impjication 
with  a  conjunction  as  antecedent: 

(rCS  =»  p(i)— p-o/-a/l(5))  =  all-prop[p)=^p-of-all 
becomes 

aU-prop{p)=p-of-all  A  rCS  =»  p{z)—p-of-aH{S). 
From  this,  LAC  produces  the  partial  function: 

function  p(x) 

aU-prop{p)=p-of-alt  A  x€5 
— *  value  (p-of-alHS)) 

where  value  (x)  means  that  z  should  be  returned  as  the 
value  of  the  function. 


3.2.2  Maintaining  Inheritance  Links 

The  second  procedure  is  necessary  to  ensure 
that  all-prop  is  stored  whenever  a  relevant  univer¬ 
sal  statement  is  made.  For  example,  when 
z£S  =*  color (z)= color- of- all{S)  is  asserted,  it  makes 
all-prop{eolor)=eolor-of-all . 

This  involves  using  the  equivalence  of  the  scheme  in¬ 
variant  as  a  left-to-right  implication,  and  using  the  left- 
hand  side  as  a  triggering  condition  for  the  procedure.  The 


resulting  demon  is  stated: 

trigger  x£5  p[x)=p-of-all{S) 
true  — ♦  all-prop[p)=p-of-all . 

3.2.3  Maintaining  Inheritable  Properties 

The  third  procedure  is  necessary  to  store  p-of-all 
when  suitable  universal  statements  are  made.  For 
example,  when  z  6  elephants  =»  color  (x)—gtey  is  as¬ 
serted,  it  adds  co/or-o/-a//(elephants)=grey  (assuming 
that  all- prop (color)=  color- of-allj. 

LAC  converts  the  scheme  assertion  into  the  form  g  =» 
p-of-all{S)—d  by  introducing  a  new  variable  v  whose 
value  is  equal  to  p(x)  and  p-of-atl[S)  in  order  to  split 
the  equality  p(i)=p-o/-all(S).  This  converts  the  scheme 
invariant: 

x£S  p{x)=p-o/-a//(S)  s  a/I-prop(p)=p-o/-iu'.' 

into 

ttll-prop{p)=p-of-ail  A  (xCS  p(i)=i») 

=»  p-of-all(S)—v. 

Choosing  the  second  conjunct  as  the  trigger  gives  the 
following  demon  procedure: 

trigger  x£S  p(x)=v 

all-prop{p)=p-of-all  -*  p-of-all(S)=v. 


3.3  Default  Inheritance 

In  many  AJ  systems  a  variation  of  the  above  scheme  is 
implemented  in  which  a  specific  value  of  property  for  an 
individual  may  be  given  which  conflicts  with  the  value  for 
the  property  given  by  the  sets  the  individual  is  a  member 
of.  In  other  words,  the  property  value  stored  on  the  set 
is  a  default  value  to  be  used  only  if  a  specific  value  for  a 
particular  individual  is  not  known.  We  can  express  the 
default  scheme  in  our  logic  using  the  DB  predicate.  The 
default  inheritance  scheme  is  basically  the  same  as  the 
direct  scheme  with  an  extra  condition; 

iDB[p[x)=±)  A  x£S  s=»  p(x)=p-o/-mo»t{5))  = 
most-pTop[p)=p-of-most 

where  J_  means  undefined. 

In  fact,  typically  a  stronger  condition  is  used  so  that  if 
there  are  two  sets  with  a  mott-prop  value  with  one  set  a 
subset  of  the  other,  then  the  smaller  set  is  used.  This  can 
be  expressed  by  adding  the  further  condition  3  5i  [5i  C 
S  A  x£  5i  A  p-of-rnost(Si)  _[_].  The  procedures  neces¬ 
sary  to  carry  out  this  scheme  are  all  derived  similarly  to 
the  ones  above. 
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§4  Related  Work 

The  specification  language  for  BC  is  logic,  which  can 
be  used  to  express  knowledge.  However,  the  main  utility 
of  BC  with  respect  to  knowledge  representation,  is  the 
facility  with  which  it  allows  knowledge  representation 
schemes  to  be  described  and  implemented.  Knowledge 
representation  schemes  may  be  defined  that  have  no 
relation  to  logic.  However,  the  ability  of  BC  to  use 
logic  encourages  the  specifier  to  relate  knowledge  repre¬ 
sentation  schemes  to  logic.  For  example,  the  formulation 
of  property  inheritance  given  in  section  3.2  is  in  terms 
of  sets,  quantification,  and  relations  between  properties. 
A  similar  scheme  inheriting  properties  from  prototypical 
elements  is  a  little  more  difficult  to  express  because  the 
relation  to  logic  is  less  direct.  Hayes  and  Nilsson,  amongst 
others,  have  argued  that  knowledge  representation  lan¬ 
guages  should  be  analyzed  using  logic  in  order  that  they 
may  be  better  understood  and  the  different  languages 
compared  more  easily  (Hayes,  1979],  [Nilsson,  1980).  BC 
allows  logic  to  be  used  as  a  tool  for  synthesis. 

Other  systems  for  building  knowledge- based  systems 
are  EKfYCIN  (van  Melle,  1980],  AGE  (Nii  and  Aiello, 
1979],  LOOPS  (Stefik  et  al.,  1983]  and  MRS  (Genesereth 
et  al.,  1983].  These  systems  supply  a  set  of  facilities 
that  are  useful  for  building  knowledge-based  systems.  BC 
takes  a  more  programming-oriented  view  in  that  it  al¬ 
lows  useful  facilities  to  be  programmed  easily.  It  may 
be  useful  for  a  system  builder  to  draw  on  a  library  of 
knowledge  representation  features  specified  in  BC,  but 
these  may  be  combined  fiexibly  and  modified  as  needed 
for  the  particular  system  and  tightly  integrated  because  of 
their  specification  in  BC.  MRS,  like  BC,  aims  to  decouple 
the  specification  language  of  the  user  from  the  implemen¬ 
tation  of  the  system.  This  goal  is  in  contrast  to  knowledge 
representations  such  as  semantic  networks  and  frame 
systems  where  the  specification  language  used  is  more 
closely  linked  to  the  actual  implemented  representations. 
MRS  provides  the  user  with  a  few  implementation  choices 
whereas  BC  provides  tools  for  the  user  to  specify  how  to 
compile  knowledge. 
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